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ABSTRACT 


The NASA Dryden Flight Research Center flew two Hyper-X research vehicles and 
achieved hypersonic speeds over the Pacific Ocean in March and November 2004. To train the flight 
and mission control room crew, the NASA Dryden simulation capability was utilized to generate 
telemetry and radar data, which was used in nominal and emergency mission scenarios. During 
these control room training sessions personnel were able to evaluate and refine data displays, flight 
cards, mission parameter allowable limits, and emergency procedure checklists. Practice in the 
mission control room ensured that all primary and backup Hyper-X staff were familiar with the 
nominal mission and knew how to respond to anomalous conditions quickly and successfully. This 
report describes the technology in the simulation environment and the Mission Control Center, the 
need for and benefit of control room training, and the rationale and results of specific scenarios 
unique to the Hyper-X research missions. 

NOMENCLATURE 


AFB 

Air Force Base 

AIP 

initial point 

ALCH 

launch point 

APWR 

power transfer point 

AREV 

reverse point 

BIT 

built-in-test 

CVT 

current-value table 

DECOM 

decommutator 

DFRC 

Dryden Flight Research Center 

EAFB 

Edwards Air Force Base 

EDW 

Edwards 

EP 

emergency procedure 

FMU 

flight management unit 

FTS 

flight termination system 

GMN 

Gorman 

GRIM 

Global Real-Time Interactive Map 

GVO 

Gaviota 

g 

gravitational unit 

HDOT 

altitude rate 

HXLV 

Hyper-X launch vehicle 

HXRV 

Hyper-X research vehicle 

INALT 

inertial altitude 


LaRC 

Langley Research Center 

LBITOR 

health summary bit 

MCC 

Mission Control Center 

NAS 

Naval Air Station 

NASA 

National Aeronautics and Space Administration 

NAWC-WD 

Naval Air Warfare Center Weapons Division 

NZF 

vertical acceleration, filtered 

NZUF 

vertical acceleration, unfiltered 

N 

z 

vertical acceleration 

PAGE 

Project Application Graphics Executable 

PCM 

pulse-coded modulation 

PDS 

Parameter Display System 

SIM3DApp 

an in-house software application 

TIE 

Test Information Engineer 

TRAPS 

Telemetry /Radar Acquisition Processing System 

WATR 

Western Aeronautical Test Range 

WINGS 

WATR Integrated Next Generation System 


INTRODUCTION 

The Hyper-X program was an experimental flight research program intended to 
demonstrate advanced hypersonic technologies (ref. 1). The primary research objective was to 
flight-test an airframe-integrated scramjet, which could pave the way for high-speed aircraft and 
the next generation of reusable launch vehicles. The NASA Langley Research Center (LaRC, 
Hampton, Virginia) was the Hyper-X program lead, and the NASA Dryden Flight Research Center 
(DFRC, Edwards, California) led the flight-test effort. Three Hyper-X research vehicles (HXRVs), 
collectively known as X-43A, were built for the Hyper-X program. All three vehicles were virtually 
identical; the main difference among them was the internal scramjet engine flowpaths. The first 
vehicle was intended to be flown to a speed of Mach 7 on June 2, 2001. It was destroyed along 
with its Pegasus® (Orbital Sciences Corporation, Dulles, Virginia) booster rocket approximately 
48 s after launch because of a loss of control of the booster (ref. 2). The second vehicle was 
successfully flown to a speed of Mach 6.8 on March 27, 2004, and effectively demonstrated the in- 
flight operation of its scramjet. All of the goals for that mission, including positive acceleration of 
the vehicle by the scramjet, were achieved. The third and final mission of the program was flown 
to a speed of Mach 9.7 on November 16, 2004, again successfully demonstrating positive engine 
acceleration. 

Control room training was an essential part of the preparation for all three Hyper-X missions. 
Previous work for flight 1 is described in ref. 3. The state of the art for the 2001 first flight was 
further improved in the interim period before the 2004 flight 2 mission. This report describes 


the control room training necessity, technological capability, and implementation philosophy for 
X-43A flights 2 and 3. 

HYPER-X PROGRAM DESCRIPTION AND TRAINING NEED 

The HXRV was an unmanned vehicle that measured approximately 12 ft long by 5 ft wide, 
and weighed approximately 3,000 lb. A modified Pegasus® rocket booster known as the Hyper-X 
Launch Vehicle (HXLV), developed by Orbital Sciences Corporation of Chandler, Arizona, carried 
the X-43A to the test condition. The HXRV was mounted to the nose of the HXLV and the mated 
HXLV-HXRV stack was carried to the launch point under the wing of the NASA B-52 airplane, 
tail number 008. After the B-52 airplane took off from Edwards Air Force Base (EAFB), the 
stack was carried over the Pacific Ocean to an altitude of approximately 40000 ft and a speed of 
Mach 0.8. It was then released from the B-52 airplane, heading due west. A few seconds after drop, 
the HXLV rocket motor ignited, propelling the stack to a separation altitude of approximately 
110000 ft. After the HXRV separated from the HXLV, the engine cowl door on the HXRV opened, 
enabling engine ignition and operation for approximately 10 s. After engine shutdown, the cowl 
door was closed, and an unpowered descent trajectory was flown to a splashdown in the Pacific 
Ocean. This flight trajectory is depicted visually in fig. 1. 
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Figure 1. The X-43A flight trajectory. 


The B-52 airplane, with the stack mated under its right wing, took off from EAFB in the 
Western Aeronautical Test Range (WATR) of DFRC, with a transition to the Naval Air Warfare 
Center Weapons Division (NAWC-WD) Sea Range for the drop, boost, experiment, descent, and 
splashdown portions of the mission. The entire mission following the drop from the B-52 airplane 
was carried out autonomously, and the HXRV was not recovered after splashdown. The expected 
flightpath over the NAWC-WD Sea Range was calculated so that any potential mission debris 
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would land in designated weapons testing zones, which are free of boat traffic during 
NAWC-WD missions. 

In order to launch the vehicle in the calculated hazard zones, the stack had to be dropped from 
the B-52 airplane precisely within a 3-min launch window while the B-52 airplane was flying at 
a speed of Mach 0.8. To meet this launch objective, waypoints along the B-52 ground track from 
EAFB were defined. Mission planners from the DFRC Operations Engineering branch carefully 
defined activities during the 45-min captive-carry flight to the launch point so that all in-flight 
vehicle preparations would take place on a timed schedule. These waypoints and the B-52 ground 
track are outlined in fig. 2. The B-52 airplane both originated and ended its flight at EAFB (noted 
by the EDW waypoint). Table 1 describes the activities onboard the B-52 airplane along the B-52 
flight profile. The entire research mission was controlled and monitored by the flight research team 
in the DFRC Mission Control Center (MCC). 



Figure 2. The B-52 ground track and waypoints prior to HXRV launch. 
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Table 1. The B-52 flight profile description and personnel responsibilities. 



Waypoint 

Mission time 
(hh:mm) 

Functions performed before next waypoint 

t# 

Label 

Description 



1 

EDW 

B-52 take-off 
from EAFB 

00:25 

B-52 pilot performs phasing maneuvers 

2 

GMN 

Landmark 

00:35 

Transition from WATR assets to NAWC-WD 
Range assets 

3 

GVO 

Last over-land 
point 

00:44 

HXLV FTS power on 

HXRV power on, built-in-test, and power off 

4 

APWR 

Power transfer 
point 

00:56 

HXLV FTS power transfer 
HXRV system checks 

5 

ALCH 

Launch point 
(in reverse) 

01:04 

Steady flight for HXLV engineers to monitor 
weather conditions in the launch box 

HXLV FTS tone checks 

6 

AREV 

Reverse point 

01:14 

HXRV system checks 

7 

AIP 

Initial point 

01:20 

(L-9) 

Final B-52 speed and altitude adjustments to 
achieve optimal HXLV launch condition 


HXRV system condition verification 
HXRV and HXLV transfer to internal power 
HXRV built-in test 
Safety hooks and pins removed 

HXLV fin actuation system power up and 
built-in test 

HXRV valves uninhibited 
HXRV adapter cameras on 


8 

ALCH 

Launch point 

01:29 

B-52 pilot launches the HXLV on cue from 
DFRC MCC 





Monitor stations onboard B-52 airplane powered 
down 

9 

GVO 

Over-land point 

01:42 

Release NAWC-WD assets and return to WATR 
assets 

10 

GMN 

Landmark 
(in reverse) 

01:51 


11 

EDW 

Landing at 
EAFB 

01:58 

Post-launch task list 
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As seen in table 1, the majority of the systems checks and maneuvers occurred in the 
launch-minus-9-minute (L-9-min) window between the initial point (AIP) and the launch point 
(ALCH). These actions included final B-52 heading, altitude, and speed correction directives; 
research vehicle internal battery, pressurized fuel system, and flight computer navigation-mode 
enabling; and launch vehicle battery squib, fin-pin, and fin-sweep activation. Operators onboard the 
B-52 airplane performed these tasks, based on direction from the DFRC mission controller. Located 
in the DFRC MCC, the DFRC mission controller received inputs from the FIXRV and F1XLV chief 
engineers, who were receiving information from the research engineers monitoring the telemetered 
downlink data. For all waypoints, and for the last L-9-min period in particular, these actions had 
to be carefully executed in order and on time, so that the B-52 airplane arrived on condition at the 
designed launch box. Preflight operations for an X-43A mission took approximately seven days to 
complete (with some personnel staffing 24-hour shifts), so there existed a substantial incentive to 
safely and successfully launch on the first attempt. A successful first-attempt launch required the 
near-perfect execution of tasks during the B-52 flight profile. For this reason, extensive control 
room training was conducted to ensure the operator, the controller, and the engineer familiarity 
with the execution of their tasks. 

During the B-52 flight to ALCH, control room engineers were expected to monitor vehicle 
health and status, reporting to the chief engineer that the systems were either on condition or that 
there was an anomaly. The project personnel defined a go/no-go list of parameters and values 
by which decisions to proceed to launch were made. Hyper-X Mission Control could not afford 
to launch this one-of-a-kind vehicle if any system was malfunctioning; conversely, each launch 
attempt cost approximately $500,000, so there was incentive not to return to EAFB unnecessarily. 
Control room training is essential to ensure that everyone has internalized their portion of the 
go/no-go parameter set. There were personnel changes between each of the X-43A flights, and 
nearly a three-year downtime between flight 1 and flight 2, so training was needed to keep everyone 
proficient at their role. In addition, each station had a primary and a backup person, so control room 
training was required to ensure that both potential participants were comfortable in their role. 

Emergency procedure (EP) checklists were on hand in case project engineers noticed any 
of the possible flight hazards during the prelaunch phase of the B-52 flight profile. Some of the 
high risks during the B-52 flight included potential leaks in the HXRV fuel system, a fire in either 
the onboard HXRV silane system or the HXLV, and high wing loading on the B-52 airplane. 
Responses to these types of emergencies ranged from venting the HXRV fuel system or jettisoning 
the entire stack, to slowing the B-52 airplane to reduce wing loading. As in the case of the 
go/no-go parameter set, execution of the emergency procedures had to be well-thought-out but 
initiated quickly, because of the risk to the flight crew, population centers on the ground, and 
mission hardware. Control room training is essential to ensuring crew familiarity with hazard 
conditions and the execution of EP response checklists. 

Training was also performed in a captive-carry mission, in which the B-52 airplane flies 
the expected profile with the HXRV and HXLV in a mated but not live condition. A captive- 
carry mission was performed prior to each of the three X-43A missions. This is, however, costly 
because of the WATR and NAWC-WD range assets [telemetry, radar, voice communications, 
flight termination system (FTS), and video systems] that must be scheduled to support the flight. 


6 


Captive-carry missions are also high-risk, because flight hardware is being exposed to potential 
damage, and the B-52 airplane is being stressed by carrying the weight of the stack. It is not practical 
to perform multiple captive-carry missions. For this reason, a simulated training environment was 
required to prepare X-43A operators, controllers, and engineers for the successful execution of 
mission tasks. 

Using the X-43A simulation equipment, it was possible to generate a pulse-coded 
modulation (PCM) telemetry stream that exactly simulated the downlink telemetry stream, and 
send it to the MCC for display to end users. In this manner, the entire B-52 flight could be practiced, 
with simulated parameter values, so that participants could leam what to expect during a nominal 
flightpath. The simulated PCM stream also allowed for the injection of parameter failures, so that 
the X-43A team could practice executing EPs. For control room training exercises, an extra person 
was used in the MCC. This training conductor was tuned in to the voice communications links 
between the mission controller and the B-52 operators, so that he could hear when commands had 
been issued or steps had been executed. The training conductor would then relay that command to 
the simulation engineer, so that the appropriate activity could be simulated in the parameter values 
in the PCM stream. 


SIMULATION ENVIRONMENT 

The NASA Dryden Flight Research Center Research Aircraft Integration Facility (RAIF) 
and its simulation capabilities support the most advanced flight research projects through all 
phases of vehicle design, development, systems integration, verification, validation, and flight-test. 
A total of nine simulation labs offer data and communication interfaces to the aircraft test bays to 
accomplish combined systems testing. Data and communication interfaces are also provided to the 
Dryden MCC supporting combined system testing, control room training, and mission planning. 

The NASA Dryden HXRV simulation was primarily developed to support verification 
and validation (V&V) of the Hyper-X avionics. The HXRV simulation is a complex six-degree- 
of-freedom (6-DOF) simulation including models for aerodynamics, engine, control system, and 
actuators. Modifications were made to the simulation to support control room training by flying a 
predefined B-52 flight profile. 

When the simulation is used for control room training, the following physical equipment is 
utilized (see fig. 3). 
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Figure 3. The HXRV simulation data flow for control room training purposes. 


For the Hyper-X missions, three PCM downlink streams were simulated (HXRV, HXLV, 
and B-52 airplane). To simulate these streams of data, a VERSAmodule Eurocard (VME) chassis 
containing three PCM simulator-encoder cards was added to the simulation configuration. 

Data from the simulation are transferred to the VME chassis through a replicated shared- 
memory interface. This interface provides for the sharing of information between different 
operating systems and hardware platforms. The simulated PCM data consists of approximately 
700 parameters (out of a total of approximately 2100 for the three Hyper-X PCM streams). 
Parameters not actively modeled in the simulation were simply assigned nominal values which 
they retained unless perturbed by an EP scenario. A problem to be faced in simulating PCM data 
is the requirement to convert the desired engineering unit output to counts. For linear calibrations, 
an inverse calibration can be directly obtained. For higher order calibrations, the Newton-Raphson 
method is used to numerically invert the polynomial. This technique is described in ref. 4. 

In addition to the PCM downlink data, the position of the B-52 airplane is tracked by the WATR 
radar. To simulate this data stream, the simulation used one of the serial outputs of the simulation 
computer to send simulated radar data to the MCC. The radar data consist of the simulation of a 
single radar site within the WATR. These data are computed in the simulation from the latitude, 
longitude, and altitude of the aircraft. These data are transmitted out of the simulation via a serial 
(RS-232) data line, with an output rate of 20 Hz to match radar processing rates. 

The B-52 flight profile was simulated by predefined latitude, longitude, and altitude values 
for the aircraft position as a function of time. This permitted simulations from aircraft takeoff, to 
the launch point, and to a landing back at EAFB. In addition, the simulation could be started at any 
point in this flight profile: for example, to focus on a particular phase of the mission. 

The use of scenario-based simulation scripts provided the flexibility necessary to introduce 
simulated failures and events at arbitrary times. For example, a scenario script was used to 
accomplish the vehicle pass/no-pass built- in-test (BIT) of the HXRV flight management unit (FMU) 
for flight- surface actuation, in response to a call for that operation from the mission controller. All 
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of the scenario-based scripts contain predefined sequences of operations (usually the assigning of 
vehicle parameter data for output via the PCM data streams). The scripts include built-in delays 
to simulate real world events. Each scenario was coded into a single script with a corresponding 
reset script. Close coordination with the training conductor via the voice network was required to 
properly execute scripts at critical times. 

MISSION CONTROL CENTER ENVIRONMENT 

The MCCs are an asset in the WATR at DFRC. Dedicated lines from WATR telemetry and 
radar equipment provide input to the Telemetry/Radar Acquisition Processing System (TRAPS) 
facility, which processes data for transmission to the MCCs, where it can be displayed to project 
engineers. In the case of a control room simulation mission, the TRAPS input is switched to use 
PCM and serial radar data from the HXRV simulation environment via dedicated fiber lines from 
the RAIF. Hyper-X missions for vehicles 2 and 3 utilized the TRAPS in the WATR Integrated Next 
Generation System (WINGS) 1.8 configuration. Further detail on the WINGS phased development 
approach can be found in ref. 5. A block diagram of the data flow between the aircraft, TRAPS, 
and MCC is shown in fig. 4. 



Figure 4. Data flow between data source, TRAPS, and MCC. 


The WINGS 1.8 system utilizes a Wyle Faboratories (El Segundo, California) Omega 
telemetry front end. Calculations on telemetry parameters to create new derived parameters are 
performed using two in-house software applications (one running at rate on every data sample, 
and a second legacy program running on a subsample of the data set). Derived calculation code 
was incorporated in the HXRV simulation so that the desired control room training values of the 
derived calculations could be produced in the simulation environment. 
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Within the WINGS 1.8 system, all PCM and radar data are recorded on magnetic analog tape 
drives. Data are also recorded in digital archive format so that the data can be converted into time 
history data and stored for long-term retrieval on DFRC internal flight data servers. 

The MCCs in the WINGS 1.8 system offer a suite of in-house software programs for 
displaying flight data. The parameter display system (PDS) is a quickly reconfigurable software 
application that displays parameter values from a current- value table (CVT). Common data display 
types in PDS include numeric readouts of parameter values, color light boxes indicating parameter 
state, message words based on discrete parameter values, bar graphs, and time history displays. A 
second CVT-based application, Project Application Graphics Executable (PAGE), is utilized when 
enhanced graphic display capabilities are required. For the X-43 A project, PAGE displays included 
visualization of fluids states and levels, and three-dimensional sketches of the HXRV with contour 
shading to represent temperature and pressure conditions at different locations on the vehicle. If 
parameters are required at rate (not sampled through a CVT), they are displayed on a physical 
strip-chart in the WINGS 1.8 MCC configuration. The two MCCs utilized for X-43A missions 
contained a total of eighteen eight-channel strip-charts at engineer workstations. For Hyper-X 
missions, a total of 51 PDS displays and 16 PAGE control room displays were maintained by the 
WATR and viewed by project personnel during missions. 

In addition to the display of telemetry and derived parameters, the WINGS 1.8 configuration 
provides a Global Real-Time Interactive Map (GRIM). The GRIM utilizes radar and aircraft data 
to display the location of an aircraft on a world map. Within the GRIM, custom restricted areas can 
be predefined on the world map. For the X-43A project, all of the waypoints were entered in the 
GRIM so that the mission controller could monitor success in passing each waypoint on condition 
as well as estimate arrival time at the next waypoint. In addition, the X-43A launch box and hazard 
debris areas over the Pacific Ocean were displayed. Range safety personnel utilize the GRIM to 
predict areas of impact in the event of FTS activation. 

The X-43A missions also employed a dedicated in-house application called the Sim3DApp. 
This program received a broadcast of HXRV parameters from a server application running on the 
TRAPS front end. The Sim3DApp uses aircraft data to display a three-dimensional visual image 
of the B-52 airplane, HXLV, and HXRV in flight. Because of the high speed and altitude of the 
HXRV experiment, optical tracking was only available for the beginning of the rocket boost phase. 
The Sim3DApp was the only visualization of the separation, experiment, and descent parameter 
identification maneuvers (PID) available for the X-43A program. 

The MCCs at DFRC are equipped with over 20 stations running either PDS, PAGE, or 
GRIM. Overhead video monitors are provided, and communications panels are available at every 
workstation to provide voice networks between research engineers, the mission controller, chief 
engineers, pilots and operators onboard aircraft, the simulation engineer (in a training situation), 
and WATR operations personnel. 
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CONTROL ROOM TRAINING SESSIONS 


Everyone who had a role in the B-52 flight and HXLV-HXRV stack launch participated 
in X-43A control room training exercises: the mission controller, the HXRV and HXLV chief 
engineers, the discipline engineers, the range control officer (RCO), the range safety officer 
(RSO), the test information engineer (TIE), the WATR equipment operators, the B-52 pilot, 
the B-52 onboard launch panel operator (LPO), and the B-52 onboard HXRV station operator 
(RV). Discipline engineers in the MCC included aerodynamics, flight systems, propulsion, 
instrumentation, guidance, navigation and control, and structures personnel for the HXRV, as well 
as HXLV development and integration engineers. 

Additionally, two other people were necessary for the control room training exercises: the 
simulation engineer and the training conductor. A dedicated voice network between the training 
conductor and the simulation engineer was established to coordinate the execution of training 
scenarios. No one else in the room could hear this voice communication, so there was an element 
of surprise if an emergency situation was introduced by the training conductor. 

Prior to flight 1, two EP training sessions were conducted using the technology described in 
ref. 3. The Hyper-X solution detailed in ref. 3 was put together in a limited timeframe of only a 
few months, with a very limited budget. The simulation capability at the time did not generate a 
PCM stream; rather, a computer in the TRAPS generated and broadcast over Ethernet directly to 
the PDS and PAGE displays. The GRIM and strip-charts in the control room could not be used 
because there was no simulated radar stream and no telemetry counts were received in the front 
end for conversion and display on strip-charts. No data recordings or postflight data could be 
generated from this method of control room training. In the nearly three-year downtime between 
flights 1 and 2, the DFRC simulation engineering branch was able to procure PCM simulator 
cards and develop the capability to send a simulated PCM stream to the TRAPS directly from the 
HXRV simulation environment. The capabilities described herein mark an improvement upon 
the capability for flight 1 : engineers are now able to view simulated strip-charts and GRIM data, 
and simulated sessions can be recorded for postflight analysis. In addition, the simulated PCM 
stream allows for the operation of the Sim3DApp for flight visualization. As a side benefit, a more 
complete set of the operational equipment is utilized by this new method so it can be verified and 
personnel can gain experience. 

Prior to flight 2, a total of seven control room training sessions were held using the HXRV 
simulation. Between flight 2 and flight 3, an additional six control room training sessions were 
held. Each session lasted between two and four hours. Each session began with a nominal B-52 
takeoff scenario. After the simulated takeoff, however, the makeup of the training session was 
markedly different, depending on whether the training had been designated as nominal or as an EP 
session. Prior to each EP training session, the training conductor and mission controller identified 
training goals and specific team training topics. The actual content and timing of the emergency 
scripts that were eventually developed for each EP training session, however, were known only to 
the training conductor and the simulation engineer. The X-43 mission controller was in training 
himself, and was not forewarned of simulation events, as everyone else on the team. 
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Within each EP training session, a progression of emergency scripts was run concurrent with 
the preprogrammed nominal simulation. The script would typically change specific parameters 
and eventually time out with one parameter or more in excess of their allowable go/no-go values. 
The EP scenarios were designed around, among other things, failed pressure sensors, a failed 
accelerometer, leaking valves, a hot telemetry transmitter, oxygen incursion within the HXRV, a 
fire within the HXRV, short-circuited battery systems, failed actuator linkages, and a structurally 
failed pylon hook. 

The discipline engineers responsible for monitoring specific parameters would react to the 
simulated emergency with a call to their respective lead engineer. If the lead engineer concurred, 
he or she would report the situation and the suggested EP to the mission controller for formal 
execution of the steps. The EPs resulted in either the continuation of the flight, an abort of the 
drop and a recycle attempt, or a mission abort and a retum-to-base call to the B-52 airplane. 
After meeting this final condition, the simulation would be paused for discussion of the scenario. 
Typically, a single EP scenario, from the start of the script to the pause of the simulation, could 
last as long as 10 to 20 min. It was not uncommon, particularly if the EP script had exposed some 
procedure deficiency or confusion in communication protocol, for the discussion to last as long as 
the EP scenario itself. 

EXPERIENCE WITH CONTROL ROOM TRAINING SCENARIOS 

To make the best use of the control room training time, the team held roundtable discussions 
to learn and refine the mission EPs. The scenarios were designed by the training conductor to 
test the team knowledge of the EPs and go/no-go lists. An example of a typical control room EP 
scenario as developed by the training conductor is shown in table 2. Table 2 represents the way 
in which the scenario was documented to the simulation engineer, who took this information and 
generated a script for the simulation environment. This particular scenario involves a subtle, and 
quite unlikely, failure of a solid-state accelerometer within the FMU. This was designed specifically 
to train the controllers to maintain vigilance on the less obvious failure parameters. The layout 
of table 2 shows the general timing used during a typical script. It also illustrates that different 
parameters were altered during the script to simulate some real-world change as a result of the 
specific failure being simulated. 
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Table 2. Emergency procedure scenario example. 


Name 

Elapsed 

Increment 

Parameter 

Off- 

Nominal 

Parameter Comment Discipline 


time. 

delta time. 

name 

nominal 

value 

name 

observing 


s 

s 


value 




EP #M3 

0 

0 

NZF 

-0.5 

1.0 g 

FMU r Systems, 

(N 






normal 

Aerodynamics, 

failure) 

0 

0 

NZUF 

-0.5 

1.0 g 

acceleration 

Unfiltered 

normal 

Controls, 

Mission 

controller 







acceleration 



0 

0 

HDOT 

-2000 

0.0 fps 

Vertical 








velocity 



0 

0 

INALT 

40000 

40000 ft 

Inertial 








altitude 



2.5 

2.5 

INALT 

37500 





5 

2.5 

INALT 

35000 


« This is a mission rule 







violation 


7.5 

2.5 

INALT 

32500 





10 

2.5 

INALT 

30000 





12.5 

2.5 

INALT 

27500 





15 

2.5 

INALT 

25000 





17.5 

2.5 

INALT 

22500 







LBITOR: 

1 

0 

Master FMU health status BIT 



BIT 1709 


1 

0 

FMU HDOT numeric value error 



BIT 0602 


1 

0 

FMU accelerometer oscillator monitor 







failure 




BIT 0601 


1 

0 

FMU accelerometer temperature sensor 







failure 




BIT 0600 


1 

0 

FMU accelerometer digitizer saturation 







failure 



20 

2.5 

it 

20000 





22.5 

2.5 

a 

17500 





25 

2.5 

a 

15000 





27.5 

2.5 

a 

12500 





30 

2.5 

a 

10000 





32.5 

2.5 

a 

7500 





35 

2.5 

a 

5000 





37.5 

2.5 

INALT 

1000 





42.5 

5 

End script with NZF, NZUF, HDOT, and INALT parameters holding last 




shown off-nominal values 
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In addition to standard parameter failures, another level of EP scenario was introduced that 
simulated a failure that did not technically violate the go/no-go procedures. For example, in the 
case of multiple and closely related sensors, the failure of one out of the set was permissible. In 
one scenario, instead of simulating an oxygen (02) incursion within the HXRV with a number of 
different 02 sensors showing over-limit 02 percentages, only a single 02 sensor was shown to go 
over the mission limit, and its value immediately jumped to the maximum value. While the initial 
urge might be to declare an emergency due to oxygen incursion, the correct response was actually 
that the vehicle had a single bad sensor and as such the go/no-go rules were not violated. Similar 
scenarios were designed around a single defective fire sensor and a single defective temperature 
sensor. 

Another form of EP scenario focused on exploring subtle aspects of the official EPs. One 
major safety concern was the health of the pylon holding the X-43A stack onto the wing of the 
B-52 airplane. If there was an unsafe condition over land, the procedures called for a mission 
abort and jettison of the pylon (with the X-43A stack still attached) in a remote desert area. In 
the scenario concerning this mission rule, the B-52 onboard HXRV station operator was told to 
report that he had indication of “two pylon lights on.” These lights are not monitored on ground 
displays, and indicated a serious problem within the pylon. This emergency was simulated at the 
L-5-min point, during an extremely busy time onboard the B-52 airplane and in the MCC. The 
immediate reaction in the MCC was to abort the drop and begin preparation for the B-52 crew to 
jettison the stack. However, since the call was made while the flight was over the Sea Range, the 
correct procedure for this case was to continue with the nominal drop mission and to jettison the 
pylon sometime after the drop. When this same scenario was repeated at a later session the mission 
controller correctly acknowledged the issue, and proceeded with the nominal predrop procedures. 

One EP scenario resulted in a considerable amount of postscenario discussion. It involved a 
script that had the S-band telemetry transmitter temperature increase significantly, but never exceed 
the maximum allowed limit of 180 °F. Then it cooled down and randomly fluctuated to represent a 
noisy signal, right around the parameter go/no-go value of 140 °F. This scenario was run at about 
the L-8-min point and resulted in the responsible engineer aborting the flight. The key, however, 
was that the script terminated with the transmitter temperature static at 139 °F, an allowable 
temperature according to the mission go/no-go rules. Although no one could dispute the engineer’s 
decision, the scenario created considerable discussion about the “what-ifs” of this situation. Many 
thought it more hazardous to the mission to be needlessly overcautious and return to EAFB for 
a later attempt, rather than continue the flight with a tolerable (according to the mission rules) 
instrument problem. Although this particular scenario does not have a straightforward solution, it 
benefited the team by exposing personnel to a possible scenario, creating an opportunity for them 
to evaluate their response to this situation. 

As mentioned earlier, the L-9-min period was the most critical for executing the HXRV 
launch, so all training sessions typically included repeated L-9-min runs to get the entire team not 
only complying with the required pace but actually improving the clarity of their communication 
and getting comfortable with the critical procedural timing. Of course, these L-9-min runs also 
provided a prime opportunity for the training conductor to implement EP scenarios to enhance the 
stress on the team, and to challenge their compliance with communications protocols during this 
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communications-heavy period. One particularly challenging EP scenario, initiated by the training 
conductor at L-3 min, presented an intentional decrease in instrument battery voltage combined 
with an increase in S-band transmitter temperature. Neither of these scenarios was intended to 
cause initiation of an EP; rather, they served as a distraction for the already busy flight systems 
team. The actual emergency situation was the intermittent change in a critical status word that 
relates to the activation of the valves onboard the HXRV. This situation occurred at L-20 s and 
required a mission abort call from the lead flight systems engineer, which was correctly handled in 
the training session. Scenarios such as this helped the personnel stay focused and perceptive, and 
to communicate with clarity in the face of a highly stressful situation such as they might face on 
the actual day of the flight. 

Other EP scenarios were specially designed to simulate unusual failures within the MCC 
infrastructure. These non-software-driven failures forced the team, and particularly the lead 
discipline engineers and the mission controller, to experience the situation live and later discuss the 
best methods to resolve the situation. For example, the intermittent loss of the telemetry link from 
the B-52 airplane or the X-43A was simulated with a technician literally pulling and reinserting the 
main PCM data input cable that was used to ultimately drive the displays in the control room. In 
one scenario, the electronics box controlling audio communications to a lead engineer was totally 
disabled. In another case, a lead engineer’s key graphic display was shut down. To accentuate the 
stress, and simulate a worst-case event, each of these latter two events were performed with no 
forewarning and were timed to occur just prior to that key individual’s team experiencing an EP 
scenario that was specifically focused on their discipline. 

An interesting training phenomenon was noticed by the training conductor near the end of 
the training for flight 2. When the final training session was announced as a nominal session it 
was noted that several members of the mission control team seemed to be complacent - they 
didn’t bring their EP books to the MCC. Clearly there was zero expectation of any emergency 
events during the nominal training. Could this expectation affect training, and ultimately team 
performance? 

The answer to this question was yes, as quickly demonstrated by an improvised test near 
the end of that session. The training conductor unexpectedly inserted an emergency script that 
simulated a no-go increase in S-band transmitter temperature just prior to the “nominal” launch. 
Neither the responsible engineer monitoring that display nor the chief engineer also overseeing the 
same data reported the anomaly, and instead allowed the mission controller to proceed with the 
launch. During post-session discussions they both stated that they did indeed see the no-go data but 
regarded it as a computer simulation anomaly because “this was a nominal training.” 

The training received during the nominal and emergency training sessions was excellent. 
But this “nominal” conduct during a session with “nominal” expectations, in the face of data 
to the contrary, seemed somewhat counter-productive to the goal of training. As a result, it was 
recommended and implemented that all future sessions be announced as simply mission training 
sessions. Except for the mission controller, who aided the training conductor with the determination 
and prioritization of training issues and goals for each session, the team wouldn’t know if the 
training session was an EP or a nominal session. The result of this slight change to the training 
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was clearly demonstrated just prior to flight 3 during a full nonstop 90-min (and therefore assumed 
nominal) training session. At L- 1 min (with no foreknowledge to anyone in the MCC) a go/no-go 
battery issue was simulated and the flight systems lead engineer immediately called the emergency 
and an abort, and the entire team responded with the appropriate emergency procedural call-outs. 
It was an excellent rehearsal and demonstrated that the team was ready for flight. 

CONTROL ROOM TRAINING BENEFIT 

The Hyper-X project personnel reaped numerous benefits from the extensive control room 
training sessions that were conducted prior to flights 2 and 3. The infrequent flights and months of 
downtime between missions made control room training essential to providing the project personnel 
with recent experience and familiarity with the control center. Everyone participating became 
more familiar with the pace of operations and the time allotted for each step in the flight cards. 
Inexperienced personnel used training to get accustomed to the monotony of monitoring virtually 
static displays for over an hour as the B-52 airplane flew offshore to the drop point. Development 
of crew discipline and focus was noticeable as multiple training sessions were conducted. Unlike 
the major portion of the B-52 flight, the final 9 min immediately preceding the drop event were 
communication- and action-intensive. This L-9-min portion of the flight was rehearsed repeatedly 
in both the nominal and the EP training sessions. In some cases, the practice revealed areas where 
a reassessment of the timing or execution of steps was required, and the flight cards were fine- 
tuned. Revisions of the flight cards were produced between each of the early control room training 
sessions as lessons learned from the exercise were incorporated into the cards. 

In addition to fine-tuning the flight cards, project personnel were able to refine the go/no-go 
list and the EP checklists based on the control room training sessions. When the training conductor 
triggered a return-to-base call based on specific parameter temperature or pressure limits from the 
go/no-go list, in many cases a lengthy discussion on the true hard limit for that parameter would 
occur, and the project was able to perfect the allowable ranges of mission parameter values. It would 
be unacceptable for a debate on a mission parameter limit to take place during an actual mission; 
repeated testing of the limits in a training session allowed for preflight debate and discussion on 
appropriate mission parameter limits. Also, in one training session, a pressure over-limit call to 
vent the onboard systems was initiated by someone outside the propulsion group based on a review 
and misinterpretation of the data values displayed. This prompted a discussion by the group, and 
as a result, the Hyper-X team redefined the allowable initiators of EPs based on this experience 
in the training environment. Crew members also identified a need to speak succinctly and present 
information to the mission controller in a standard order every time, so an abbreviated language 
about EPs was born out of the practice in the control room training sessions. Repeated emergency 
scenarios in the final L-9-min commotion helped the personnel practice staying focused, perceptive, 
and clearheaded in the face of highly stressful situations. 

The control room training exercises utilizing the simulation also allowed for verification of 
the calibration information contained in the Calibration Information Management System (CIMS) 
file. When the simulation was used to reverse-engineer a counts value for a desired engineering 
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unit (EU) value, the displayed value in the WATR could be used to test whether the calibration 
information was valid and functional. 

While the flight and control room crews benefited from the training sessions, WATR personnel 
involved were also receiving valuable practice and testing opportunities. Range operations personnel 
became familiar with the setup and execution of Hyper- X missions, because without these simulated 
sessions, there would have been few opportunities to practice configuring the control room for end 
users. The TIE was able to test all 67 control room displays, the derived calculation code, and strip- 
charts with the simulated PCM stream. Engineers could see their displays “in action” rather than 
in a static testing mode, and that triggered many modifications to the way data were calculated and 
displayed to the end user. In the early development of the capability, the ability to record sessions 
and generate postsession time-history data files proved valuable to the training conductor, TIE, and 
simulation engineer for testing and verifying the control room training scenarios. Finally, using a 
simulated PCM stream was the only means of verifying the Sim3DApp used for visualization of 
stack ascent, separation event, HXRV experiment, and HXRV descent into the ocean. 

CONCLUSION 

The capability to simulate multiple telemetry streams and radar data in order to train flight 
and mission control personnel for a flight project at the NASA Dryden Flight Research Center 
has been successfully demonstrated. This technology was used to simulate in-flight emergency 
scenarios for the Hyper-X program and provide a means for the crew to practice several mission 
profiles. 

These training sessions: 

• Improved crew response and communications 

• Verified and improved control room displays 

• Verified calibration coefficients 

• Verified operational equipment 

• Improved checklists and go/no-go limits 

• Resulted in a safer mission. 


Crew training via simulated in-flight scenarios in the Dryden Mission Control Centers was an 
essential part of the preparation for Hyper-X research missions. Control room training was a cost- 
effective means of ensuring both flight safety and mission success for the Hyper-X air launches. As 
both the crew and the simulation training team gained familiarity with the capabilities of the system, 
the fidelity of the training sessions was improved and project personnel were able to perfect their 
data displays, go/no-go launch conditions, emergency procedures, and the flight cards. The control 
room training environment served as a nonthreatening place for personnel to leam their roles and 
practice responding efficiently to highly stressful simulated emergency scenarios. According to 
Dryden Hyper-X chief engineer Griffin Corpening, “this hard work and training paid off (in the 
form of) three flawless captive-carry flights and three flawless launch operations.” 
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